The goal of this PR is to define a repo limit size using "no-worsen" approach (allow things that do not increase or decrease the size on disk eventually) I think org and user level restriction could come later.
Thanks to @sapk as this is a continuation of his work that was started in #7833
Would address (except for LFS): #3658
Jan 22, 2026 Updated - no more DB limit. Only config and a run-time switch in UI for admin.

**Screenshots:**

global limit setting for admin resets after restart should manage in config

individual repo size limit for a repository admin (visible to a user who is owner of the repo)

app.ini with settings

;; Specify a global repository Git size limit in bytes. -1 - Disabled, 0 - limit to zero bytes
;; Standard units of measurements for size can be used like B, KB, KiB, ... , EB, EiB, etc or if not provided - bytes
;; If limit is reached and operation doesn't increase disk consumption operation would be allowed
;; This is experimental and subject to change
;GIT_SIZE_MAX = -1

;; Specify a global repository LFS size limit in bytes. -1 - Disabled, 0 - limit to zero bytes
;; Standard units of measurements for size can be used like B, KB, KiB, ... , EB, EiB, etc or if not provided - bytes
;; If limit is reached and operation doesn't increase disk consumption operation would be allowed
;; This is experimental and subject to change
;LFS_SIZE_MAX = -1

how currently push is rejected if limit is reached

TODO: (1)

• Calculate Push Size (sapk had still have some corner-case to test mostly to not block deletion and some force push)
• Edit max repo size
• Enforce repo size
• Fix tests
• Add a global per repo limit in config for LFS and for GIT separately. - DEFAULT: -1 - not enabled. if 0 would be enabled and limit to 0B. (should accept bytes, K, and M, and G, may be T like 1000 - 1000 bytes, 1K - 1 kilobyte. 1M - 1 M megabyte.)
• UI to enable/disable set global repository limit (Note. The setting get's reset every gitea restart to what it was in the config)
  Jan 22, 2026 Removed- [x] Add ability to have the feature on or off in the config (repository section in config), default - FALSE - A boolean parameter in config to enable the size-feature checking. If it is enabled then size limit is enforced. There is a field to edit size limit in the repo settings UI. The size limit is taken into account. If disabled then repo size limit is ignored. We can leave the size limit field in the repo settings UI and allow to edit it, however, the color of size limit value should be grayed. (telling that it is not working)
  the config parameter - ENABLE_SIZE_LIMIT = true/false
  - [x] Add ability to have a global repo limit per installation that is enforced unless an individual repo size limit present (repository section in config) - DEFAULT: 0 - global default size limit for any repo where individual size limit is not defined. if 0 - no limit if >0 limit is set so that if a repo has 0/undefined sizelimit this configuration limit will be used instead. Config parameter REPO_SIZE_LIMIT = XXXX (should accept bytes, K, and M, and G, may be T like 1000 - 1000 bytes, 1K - 1 kilobyte. 1M - 1 M megabyte.)

TOFIX: (2)

• UI operations trigger 500 error when repo is over - present a correct message instead

• Console operations when failing doesn't provide a correct error message - now it does

• Unable to push anything that decreases size of repo and a relevant test scenario - now is possible

• Documentation update

• Add a delete test - gitea should accept any action (tag, branch, commit, file) that should reduce the repo in size. Since delete doesn't remove any data, we hope for git gc to reduce size after delete eventually. Ideally we should also run git gc and confirm size release.

• Added usage of git verify-pack -v to speed up size assessment, added usage of git batch-check; git cat-file -s now uses workers. If pack files are present then compressed size is used as it is closer to real disk usage on both repo analysis and push analysis.

• Update algorithm to calculate on incoming push lfs object sizes and exclude their size from the push size (LFS objects are included into push size by git by default)
  Jan 22, 2026 Removed- [x] Rework Size Checking enablement to use only REPO_SIZE_LIMIT from config -1 - not enabled, ignore any size limits, 0 - no global size limit, but respect the limit of repo, any other value - global size limit is set, but respect the limit set on repo individually. (After LFSSize and GitSize split update the code of size checking to exclude the LFS for now DmitryFrolovTri/gitea-limit-repo-size#18)

• Remove any mention of the EnableSizeLimit parameter. (Remove any mention of the EnableSizeLimit parameter. DmitryFrolovTri/gitea-limit-repo-size#20)

• Update code to use GitSize value from repo instead of Size. (Update code to use GitSize value from repo instead of Size. DmitryFrolovTri/gitea-limit-repo-size#21)

• Optional: Update the repo size field in UI should be with human editable text (The Size limit field in the repository overview should use the FileSize and there should be no scroll for numbers DmitryFrolovTri/gitea-limit-repo-size#19)

Jan 22, 2026 Removed- [x] Add ability to count LFS Size towards Repo Size for those who store LFS on the same disk as the repo itself.

Note: If functionality to control size is enabled and a push triggers a size check (it's size would breach the limit) then push will be accepted only if total size of not referenced objects (removed size) is over or equal to total size of newly added objects in push. Or in other words pushes are accepted if they are under or at the limit after the operations they do OR if they are breaching the limit only if they don't grow disk space. Since git controls when not referenced objects are purged and it's not fast this condition could last for a while. Administrator of instance could speed it up via following steps:

1. Done from the data folder of the specific repository on the gitea server <path_to_gitea_server_folder>/data/gitea-repositories/<user>/<repository>:

git reflog expire --expire-unreachable=all --all
git gc --prune=now

2. Execute Git GC from the UI.
   This would free up all not referenced objects and update repository size in UI. On next push (if push size is smaller then limit) adding new objects will be allowed.
3. There is a known bug in LFS - raised an issue The LFS maintenance scripts after orphaned objects removal do not update repo.LFSSize after operations. #36169 so that repo.LFSSize is actually updated after LFS garbage collect / LFS storage doctor. Now can't decrease the LFS size occupied at all. So if user reaches the limit he might get stuck.

• Review the need to test doDeleteCommitAndPush type of test - Not Needed - Reverted
• Prevent the upload as well in case it would breach the size limit on the repo. (server.go) here it can't be "no-worsen" it will fail if new size over the limit:

$ git lfs push origin main --all
batch response: LFS size 1.7 GiB would exceed limit 1.0 MiB

• Enforce repo size with lfs added
• adequate error messages to user upon lfs operation (if they are failed due to size)
• add tests for lfs sizes
• add lfs specific repo limit size configuration option and UI to edit

NEXT PR (4)

• prevent migrating (mirror) repositories that would overflow the limit / Extend the size checking logic into the code for repository mirrors. We shouldn't mirror if that would breach the limit on repo/user/org level
• Develop a go-git variant for size calculation
• Add a test to confirm that already existing in the store objects do not count as new in both server.go and hook_pre_recieve.go
• Not agreed yet. Update Git GC logic to allow for faster space release

EVEN further PR (5)

• Add a per user/organisation account size limit that can be set by administrator (Global per repo used everywhere unless a per repo limit is set. If an action crosses the border of such account limit the action should be denied)
• implement an organization/user level size restriction
• Add a hard limit on repository size that would cancel any operation: (config option with percentage of overage, special message). No commit can be accepted in such case. This is because the limit is "soft" i.e. it does allow to increase space, but it would already prevent push that moves the repository over.

Related: #3658 #7833